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Reply to Examiner's Answer 



1 Introduction 

The Examiner rejected Claims 1,11 and 22 under 35 U.S.C. §1 02(e) as being 
anticipated by U.S. Patent No. 6, 725, 272 B1 ("Susai"). The Appellant respectfully disagrees 
with the Examiner. Consequently, this appeal was filed. 

The Examiner responded to the Appeal Brief filed by the Appellant on July 19, 2006 and 
the Reply to Notice of Non-Compliant Appeal Brief filed by the Appellant on August 9, 2006 
("Appeal Brief) with the Examiner's Answer to the Appeal Brief of December 6, 2006 
("Examiner's Answer"). In the Appeal Brief, the Appellant's argued as follows: a) the cited prior 
art-Susai-does not teach or suggest inquiry data, b) Susai does not teach or suggest responding 
to a request for inquiry data by providing the requested inquiry data from a cache memory and 
c) Susai does not teach a router configured to respond to a request for inquiry data 
corresponding to one of the target devices that is busy using stored inquiry data. See Appeal 
Brief, pages 17, 19 and 24 and Examiner's Answer, pages 11,12 and 13. Appellant respectfully 
maintains that the present invention is novel in light of Susai. 

To anticipate a claim, a single reference (or event) must expressly or inherently disclose 
each and every limitation of a claim. See Moba B.V. v. Diamond Automation, Inc., 325 F.3d 
1306, 1233 (Fed. Cir. 2003) and Hybritech Inc. v. Monoclonal Antibodies, Inc., 802 F.3d 1367, 
1379 (Fed. Cir. 1986). The entire prior art reference may be reviewed for anticipatory material, 
not just the claims of the reference (if the reference is a patent or printed patent publication). 

The Appellant respectfully submits that Susai does not disclose or teach each and every 
claim limitation of Claims 1 , 1 1 and 22 and therefore does not anticipate Claims 1 , 1 1 and 22. 

2 Inquiry Data 

Claims 1,11 and 22 recite the use of inquiry data. The Examiner contends that Susai 
teaches the use of inquiry data. Applicant respectfully disagrees: Susai does not teach the use 
of inquiry data. 

As clearly described in the Specification, inquiry data relates to the properties of a target 
device itself and "may include the serial number, manufacturer, configuration, version number, 
or similar data" corresponding to the target device. See Specification, paragraph 0005. A 
request for inquiry data, or an inquiry command, is thus not simply a request for any data stored 
on a target device, but is a request for data about the target device itself. Inquiry data is 
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generally data which is static or which changes relatively infrequently. See Specification, 
paragraphs 0005 and 0006. Inquiry data corresponding to a target device is initially held at the 
target device itself and must be loaded into the cache of a router from the target device itself. 
See Specification, figure 3 and paragraph 0030. Inquiry data is not calculated or determined at 
the router but instead is data which comes from the target device. See Specification, paragraph 
0030. 

Requests for inquiry data may be submitted for various reasons. For example, when a 
new host is booted, it checks to see which other devices are connected to the network. See 
Specification, paragraph 0006. Hosts may also periodically use inquiry commands to obtain 
information regarding the availability of devices on the network. See Specification, paragraph 
0006. If a device responds to the request, the host will receive the responsive inquiry data and 
will be aware that the device is available. See Specification, paragraph 0006. If the device 
does not respond, the host may assume either that the device is no longer connected to the 
network or that the device is no longer functioning properly. See Specification, paragraph 0006. 

2.1 Examiner's Reasoning 

The Examiner asserts that Susai teaches inquiry data. The Examiner states: 



Susai teaches an apparatus, method and computer program product for 
guaranteeing network client-server response time while providing a way of 
putting the client on-hold when the response time temporarily prohibits, access to 
the requested server (See abstract). Susai teaches client sending request for 
information to Interface unit 202 (See Column 5, lines 4-7, 11-15), in response to 
the client's request Interface unit 202 determines waiting time to access a 
selected server for the client and displays that to the client. Response time 
(waiting time for the client) is interpreted to be the "Inquiry data". Inquiry data is 
not defined in claim. Additionally in the specification Inquiry data may also 
include availability of a network device (See Paragraph [0006]). Where the 
availability of a network device may mean the wait time to access a network 
device. For example, a network device may be available in 5 minutes. Therefore 
Susai's wait time is interpreted to be "Inquiry data". See Examiner's Answer, 
pages 11-12. 
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The Examiner seems to be interpreting paragraph 0006 of the Specification as equating 
inquiry data with the "availability of a network device." Based on this interpretation of inquiry 
data, the Examiner equates response time (waiting time for the client) determined (i.e. 
calculated) by an interface unit with inquiry data. Thus the Examiner appears to equate waiting 
time or response time of a device determined by an interface unit with inquiry data. 

2.2 Flaws in the Examiner's Reasoning 

The Examiner seems to reason that since "inquiry data is not defined in claim", the 
meaning of inquiry data is mutable. This is improper. As described in the Specification, inquiry 
data relates to the properties of a target device itself and "may include the serial number, 
manufacturer, configuration, version number, or similar data" corresponding to the target device. 
See Specification, paragraph 0005. Inquiry data is generally data which is static or which 
changes relatively infrequently. See Specification, paragraphs 0005 and 0006. Inquiry data 
corresponding to a target device is initially held at the target device itself and must be loaded 
into the cache of a router from the target device itself. See Specification, figure 3 and paragraph 
0026 and 0030. A request for inquiry data, or an inquiry command, is thus not simply a request 
for any data stored on a target device, but is a request for data about the target device itself. 

2.2.1 "Availability of Network Device" Not Inquiry Data 

In rejecting Claims 1,11 and 22, the Examiner erroneously interprets paragraph 0006 of 
the Specification as showing that inquiry data includes the availability of the network device and 
then makes the leap that response time is a measure of availability and is therefore inquiry data. 

To quote the Examiner: "Response time (waiting time for the client) is interpreted to be 
the "Inquiry data". Inquiry data is not defined in claim. Additionally in the specification Inquiry 
data may also include availability of a network device (See Paragraph [0006]). Where the 
availability of a network device may mean the wait time to access a network device. For 
example, a network device may be available in 5 minutes. Therefore Susai's wait time is 
interpreted to be "Inquiry data"." See Examiner's Answer, pages 1 1-12. 

Paragraph 0006 of the Specification, however, recites: 



Inquiry commands may be submitted to device 15 for various reasons. For 
example, when a new host is booted, it checks to see what other devices are 
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connected to the network. Hosts may also periodically use inquiry commands to 
obtain information regarding the availability of devices on the network. If a device 
responds to the command, the host will receive the responsive inquiry data and 
will be aware that the device is available. If the device does not respond, the host 
may assume either that the device is no longer connected to the network, or that 
the device is no longer functioning properly. 

The Examiner appears to have misinterpreted "Hosts may also periodically use inquiry 
commands to obtain information regarding the availability of devices on the network" as 
supporting the supposition that inquiry data includes the availability of the network device. 
However, as is apparent from paragraph 0006 as a whole, it is the fact the device responds with 
inquiry data that shows the availability of the device, not the content of the inquiry data itself . 
Consequently, paragraph 0006 does not support the Examiner's erroneous conclusion that 
inquiry data includes "the availability of a network device" and therefore response time is inquiry 
data. 

Moreover, the availability of a device as determined at an interface device is not inquiry 
data as defined in the specification: it does not refer to the properties of a target device itself, 
such as the serial number, manufacturer, configuration, version number, or similar data. The 
response time/availability of a device is, in part, a function of network traffic and is not a property 
of the device itself and is not identity data for the target device. The availability of a device is 
inherently subject to rapid change because it is a function of network traffic and thus-unlike 
inquiry data-is not "static" or does not change "relatively infrequently." 

2.2.2 Response Time and Waiting Time are Not Inquiry Data 

To further confuse matters, it appears that the Examiner has conflated "response time" 
and "waiting time" in Susai to have a single meaning. However the meaning of response time 
and waiting time taught by Susai differ: response time is an estimate of how long the server will 
take to respond and is used to determine if a client will be put on-hold; waiting time is how long 
a client will be put on hold and is used to determine which on-hold content the client will receive. 
See Susai, figure 3 and column 7, lines 57-67. 
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2.2.2.1 Response Time and Waiting Time do Not Come From Target Device 

As described in the Specification, inquiry data is held at the target device and copied to 
the cache of the router. It is the purpose of the invention to allow host devices to retrieve this 
information that identifies the target devices (i.e. provides the properties of the target device 
such as device type, etc.) when the target device is itself unable to respond to the request for 
inquiry data. For example, paragraph 21 of the Specification states: 

As noted above, host devices generally use the inquiry command to obtain 
information regarding the availability of devices on the network. If a host is 
booted up and a device on the network is busy, the device can't respond to the 
inquiry command. A mechanism is therefore necessary to provide the 
responsive data, thereby keeping the host's inquiry command from timing out 
and keeping the host from assuming that the device is not available. 

Thus, the inquiry data is data that is initially held at the target device to specify the properties of 
the target device and is copied to and stored in the cache of a router. 

The Examiner appears to have mistaken data calculated at an interface unit with storing 
inquiry data which comes from a target device in the cache of a router. Inquiry data comes from 
a target device and is stored at a router, not calculated. By contrast, the interface unit of Susai 
calculates the response/waiting time. Thus, in Susai, response/waiting time is not passed to the 
interface unit by the target device, but instead originates at the interface device itself. The 
response/waiting time generated by the interface device of Susai is calculated data never held 
by the target device. Because the response/waiting time calculated by Susai is not held at the 
target device, the response/waiting time of Susai cannot be inquiry data. Moreover, because 
inquiry data is data regarding properties of the target device itself, such as the serial number, 
manufacturer, configuration, version number, or similar data, it is not amenable to calculation or 
determination by an interface unit. Because response time and waiting time is not relatively 
static data about the target device initially held at the target device, but is instead data 
calculated at the interface unit, response time and waiting time are not inquiry data. 
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2.2.2.2 Waiting Time is Not About the Target Device 

Waiting time-which is returned to the client-cannot be inquiry data because it does not 
define the properties of the target device. Instead, waiting time appears to describe how long a 
client will receive content from an on-hold server. See Susai, column 7, lines 55-65. How long a 
client will receive content from an on-hold server is information unrelated to the properties of the 
target device. 

2.2.2.3 Response Time Not Returned to Client 

While the waiting time is returned to a client, Applicant cannot find any portion of Susai 
which teaches returning the response time to the requesting client. Instead it appears that 
based on the determined response time, a server "displays options to the user (via the client) for 
being put on-hold." See Susai, column 7, lines 50-55. That is, a menu of on-hold options is 
returned to the client, not the response time. Because the response time is not returned to the 
client, even assuming arguendo that response time could be equated with inquiry data, Susai 
does not anticipate Claims 1 and 22 because Susai does not teach providing the response time 
to the client. 

2.3 Susai does not teach Inquiry Data 

Applicant respectfully submits that Susai does not teach inquiry data. The 
response/waiting time/availability of a device cited by the Examiner is not inquiry data because it 
is not data that relates to the target device (such as serial number, manufacturer and other 
identifying information) that is initially held by the target device. Because Susai does not teach 
inquiry data, Susai cannot anticipate Claims 1, 11 and 22. 

3 Responding to a Request by Providing the Requested Data from a Cache Memory 

The Examiner contends that Susai anticipates Claims 1 and 22. Claims 1 and 22 both 
recite: "storing inquiry data corresponding to a target device in a cache memory; receiving a 
request for the inquiry data corresponding to the target device; reading the inquiry data from the 
cache memory; and providing the inquiry data corresponding to the target device in response to 
the request." Thus, the router of Claims 1 and 22 stores inquiry data corresponding to a target 
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device in cache memory and uses the cached inquiry data to respond to requests for inquiry 
data. 

As described in the Specification, for example, a router routes data between the hosts 
and target devices. See Specification, paragraph 0022. When the router receives inquiry data 
from a target device, the router performs both the functions of: i) storing the inquiry data in a 
cache (i.e., for responding to later requests for inquiry data from the same target device) and ii) 
routing the inquiry data to the requesting host. See Specification, paragraph 0029 (stating "the 
router does two things with the data: it stores the data in its cache; and it forwards the data to 
the host device that originally requested it"). Because the router of Claims 1 and 22 stores 
inquiry data in a cache memory, it can respond to requests for the inquiry data. When the router 
receives a subsequent command from the host device and the target device is busy, the router 
will provide a response if possible. "In order to provide a response, the router must have the 
data necessary to service the request stored in its cache. It therefore, checks to the cache to 
determine whether or not it has the data. If the data is stored in the cache, the data is read from 
the cache and then forwarded to the host device in response to the inquiry command." See 
Specification, paragraph 0030. This allows the router to respond on behalf of the target device 
with the requested inquiry data when the target device is busy. See Specification, paragraph 
0026. 

3.1 Examiner's Reasoning 

The Examiner states: 

Susai teaches receiving request from client (See Column 5, lines 4-7, 11- 
15) and displaying wait time "respond" to the client (See Column 7, lines 57-64). 
Susai teaches Interface unit 202 could be a proxy cache (See Column 4, lines 
22-24), which is interpreted to be "cache memory". The interface unit 202 being 
a proxy cache then transmits the response time to the client. Since the response 
time "Inquiry data" is determined at the interface unit 202 and the response time 
is transmitted from the interface unit 202, then the response time "Inquiry data" is 
inherently stored on the interface unit 202 (See Column 6, lines 44-49 and 
Column 4, lines 22-24). Therefore Susai teaches "Storing Inquiry data in a 
Cache Memory". 

Susai also teaches the client send a request to determine whether 
content may be obtained instantaneously or with a wait time from a selected 
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server "target device" (See Column 5, lines 4-7 and 11-15). Therefore, Susai 
teaches receiving a client request for wait time on a selected server i.e. "request 
for inquiry data corresponding to target device". 

Also, as discussed above, the interface unit 202 that's the proxy cache 
inherently stores the wait time "Inquiry data" in its memory where the wait time is 
then transmitted by the interface unit to the requesting client (See Column 6, 
lines 43-46 and Column 7, lines 57-64). Therefore, Susai teaches "reading 
inquiry data from the cache memory". 

Finally, Susai teaches the wait time "Inquiry data" is sent to the 
requesting client in response to the client request (See Column 7, lines 57-64). 
Therefore Susai teaches, "providing the inquiry data corresponding to the target 
device in response to the request". See Examiner's Answer, pages 12-13. 

The Examiner seems to reason that receiving a request for data at an interface unit and 
the interface unit providing the response/waiting time in response teaches "receiving a request 
for the inquiry data corresponding to the target device" and "providing the inquiry data 
corresponding to the target device in response to the request" because the response/waiting 
time is returned in response to a request for data. 

3.2 Flaws in the Examiner's Reasoning 

3.2.1 Susai does not Teach Inquiry Data 

For reasons set forth above, Applicant respectfully submits that the genesis of the 
Examiner's error in the interpretation of the present invention lies in interpreting inquiry data to 
include the response/waiting time of a network device determined at an interface unit. Because 
this is not inquiry data, as discussed above, Susai does not teach inquiry data and cannot 
anticipate Claims 1 and 22 by "storing inquiry data corresponding to a target device in a cache 
memory; receiving a request for the inquiry data corresponding to the target device; reading the 
inquiry data from the cache memory; and providing the inquiry data corresponding to the target 
device in response to the request." 
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3.2.2 Susai does not Teach Responding to a Request by Providing the Requested Data 

As taught by Susai, no matter what request is sent to a busy server, the interface unit 
returns the waiting time. See Susai, figure 5, and column 8, lines 50-55. Susai teaches 
determining a waiting time and providing that waiting time to the requesting client regardless of 
the client request. See Susai, figure 5, and column 8, lines 50-55. Thus, according to the 
teaching of Susai, if a client requests a webpage, the client will receive a waiting time instead of 
the requested webpaqe . Consequently, the waiting time returned in Susai is not the requested 
data . Thus, the Examiner's reasoning that returning a response/waiting time in response to a 
request for data as taught by Susai teaches "receiving a request for the inquiry data 
corresponding to the target device" and "providing the inquiry data corresponding to the target 
device in response to the request" is flawed because the waiting time is not the requested data 
(i.e., there is no waiting time request from the client). Thus Susai does not teach the present 
invention because the present invention teaches returning inquiry data in response to a request 
for the inquiry data whereas Susai teaches initially returning non-requested data (in cases 
where the waiting time is returned). 

3.3 Susai does not teach Responding to a Request by Providing the Requested Data 
from a Cache Memory 

For the above reasons, Applicant respectfully submits that Susai does not teach 
responding to a request by providing the requested data from a cache memory as taught by the 
present invention because Susai does not teach providing inquiry data in response to a request 
for inquiry data. Because Susai does not teach the above limitations, Susai cannot anticipate 
Claims 1 and 22. 

4 A Router configured to Respond to a Request for Inquiry Data Corresponding to One of 
the Target Devices that is Busy Using Stored Inquiry Data 

The Examiner contends that Susai anticipates Claim 11. Claim 11 recites: "the router is 
configured to store inquiry data received from the one or more target devices and to provide at 
least a portion of the stored inquiry data in response to a request for inquiry data corresponding 
to one of the target devices that is busy." Thus, according to Claim 1 1 , the device that routes 
data between hosts and target devices also stores inquiry data received from the target devices. 
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When the router receives a request for inquiry data corresponding to a target device that is 
busy, the router can respond with the stored inquiry data. 

4.1 Examiner's Reasoning 

Once again, the Examiner equates a response or waiting time which is determined (i.e. 
calculated) at an interface unit with inquiry data. 
The Examiner states: 

Susai teaches interface unit 202 could be a router (See Column 4, lines 22-24). 
Susai teaches receiving request from client to Interface unit 202 (See Column 5, 
lines 4-7, 11-15) and Interface unit 202 determines response time and displays 
the response time to the client (See Column 7, lines 57-64). Response time 
(waiting time for the client) is interpreted to be the "inquiry data". Interface unit 
202 inherently stores the response time. The response time indicates whether 
the server or network device is busy (availability). Therefore Susai teaches "a 
Router Configured to Respond to A request for Inquiry Data Corresponding to 
One of the Target Devices That is Busy Using Stored Inquiry Data". 

The Examiner's reasoning parallels the reasoning described above in section 3.1. Namely, the 
Examiner seems to reason: i) that because the interface unit determines response/waiting time, 
Susai teaches a router "configured to store inquiry data received from the one or more target 
devices" and ii) that because the interface unit returns a response/waiting time in response to a 
request for data, Susai teaches a router configured to provide "the stored inquiry data in 
response to a request for inquiry data." 

4.2 Flaws in the Examiner's Reasoning 

For reasons set forth in greater detail above, the Applicant contends the Examiner's 
reasoning is flawed and Susai does not anticipate the present invention. 

Claim 1 1 explicitly recites receiving inquiry data from a target device. Because Susai 
teaches an interface unit which determines a response/waiting time, Susai does not teach a 
router "configured to store inquiry data received from the one or more target devices." There is 
nothing in Susai teaches or suggests receiving the response time from a target device. See 
Susai, column 5, lines 55-60 (teaching calculating the response time). At least because the 



Attorney Docket No. 
CROSS1490 



12 



10/064,080 
Customer ID: 44654 



response/waiting time of Susai is calculated at an interface unit and not received from a target 
device, Susai does not teach storing inquiry data received from a target device . 

For reasons similar to those set forth above in section 3.2.2, Applicant contends that 
because Susai teaches an interface unit which returns a response/waiting time in response to a 
request for data, Susai does not teach a router configured to provide "stored inquiry data in 
response to a request for inquiry data." That is, for example, in response to a request for a 
webpage, the system of Susai would return a waiting time. See Susai, column 8, lines 50-55, 
column 10, lines 49-61 and figure 7. By contrast, Claim 1 1 clearly recites returning inquiry data 
in response to a request for the inquiry data . Accordingly, Susai cannot anticipate Claim 1 1 . 

4.3 Susai does not teach a Router configured to Respond to a Request for Inquiry Data 
Corresponding to One of the Target Devices that is Busy Using Stored Inquiry Data 

For the above reasons, Applicant respectfully submits that Susai does not teach inquiry 
data or a router configured to respond to a request for inquiry data corresponding to one of the 
target devices that is busy using stored inquiry data because Susai does not teach: i) a router 
configured to store inquiry data received from a target device or ii) a router configured to provide 
inquiry data in response to a request for inquiry data. Because Susai does not teach the above 
limitations, Susai cannot anticipate Claim 11. 

5 Conclusion 

As explained above, the Appellant believes that Susai does not show each limitation of 
claims 1,11 and 22, and that the corresponding rejection of claims 1-19 and 22 should properly 
be withdrawn. The Appellant therefore respectfully requests that all of the rejections be 
withdrawn and that all the pending claims be allowed. 
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Applicant does not believe any fees and due and owing. If any fees are required, or if 
any amounts have been overpaid, please appropriately charge or credit those fees to Deposit 
Account No. 50-3183 of Sprinkle IP Law Group. 
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